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Description 



SYSTEM AND METHOD FOR CREATING 
DYNAMIC FOLDER HIERARCHIES 

Background of Invention 

[0001] The present invention generally relates to the field of or- 
ganizing and inter-relating data files. More particularly, 
the present invention relates to a system and associated 
method for a dynamic folder hierarchy such that docu- 
ments, items, or object groups stored without external 
organization provided by a static folder hierarchy can be 
viewed by the user in a dynamic folder hierarchy that 
adapts to modifications of the documents, items, or ob- 
ject groups without manual intervention. 

[0002] As used herein, the term "folder" refers for example to a 
named collection of related items that can be retrieved, 
moved, and otherwise manipulated as one entity. "Folder- 
ing" or "linking" is a process where a content management 
system manages or controls the creation, retrieval, editing 
and distribution of content within an information process- 



ing system. Foldering or linking is the act of forming a 
"link" relationship between two Items. Generally, the con- 
tent management system enables an end user to create a 
folder in the content management system and file it into a 
library by interacting with a suitable application. 

[0003] Foldering is a generic concept of grouping documents or 
entities. A folder hierarchy can be used as a classification 
method to categorize documents, helping to narrow a 
search space for documents and providing a natural 
method of navigating documents. Examples of providing 
the folder hierarchy can be found in file systems such as, 
for example, the NTFS on Windows platforms, or in an 
email repository such as, for example, Lotus Notes®. 

[0004] Conventional foldering mechanisms require a user to 

manually maintain the placement of documents in a folder 
within a folder hierarchy. When the content of a document 
is changed, users have to determine a location for the 
document within the folder hierarchy that matches the 
new content of the document. The possibility of misplac- 
ing documents in a folder hierarchy is relatively high. 
Once the document is misplaced, it can be difficult to lo- 
cate. 

[0005] Auto foldering systems address the issues of manual 



foldering. Conventional auto foldering systems automati- 
cally place the documents in folders using a predefined 
criterion based on the properties or content of the docu- 
ment. OLE_LINK2Although this technology has proven to 
be useful, it would be desirable to present additional im- 
provements. OLE_LINK2 Using an auto foldering system al- 
lows association of a document with many folders. If 
changes in the content of such a document occur fre- 
quently, the processing overhead involved in re- 
evaluating the foldering criteria and placing the document 
in appropriate folders is high. 
[0006] Conventional dynamic foldering systems address the is- 
sues of manual foldering while reducing processing over- 
head of auto foldering systems. Instead of requiring static 
placement of a document in one or more specific folders, 
a criterion (or criteria) is defined for each design-time 
folder to describe which documents are associated with 
the folder. When during run-time a corresponding dy- 
namic folder is accessed via query or path navigation, a 
collection of documents is evaluated against the defined 
criteria. Those documents in the collection of documents 
that satisfy the criteria of the dynamic folder appear as 
members of the folder. 



[0007] one conventional dynamic folder system provides a 

mechanism to populate "smart" folders with documents 
retrieved from a search executed upon a "folder 
open"command [reference is made to "Smart Folders in 
Greenpasture", G5 Desktop Technical Note, 
http://www.greenpasture.com/teknotes/teknote_g5_desk 
top_03.pdf]. The smart folders contain pointers to docu- 
ments returned from a saved search. To create a smart 
folder, a user first defines and saves a search. The user 
then creates a smart folder and associates the saved 
search with the smart folder. The system runs a search 
each time the user opens the smart folder and fills the 
folder with documents returned from the search. The re- 
sult of the smart folder is the result of joining the nested 
queries of the nested folders [reference is made to 
http://www.greenpasture.com/demos.html]. One docu- 
ment can reside in any number of smart folders. The user 
may configure smart folders to search the entire library or 
base a search upon the position of the smart folder in the 
folder hierarchy. In the latter case, a smart folder returns 
only documents that are stored in folders at or below its 
own level in the hierarchy. 

[0008] Another dynamic foldering system provides three ways of 



defining a folder using metadata: explicit folder creation, 
template-based folder creation, and rule-based folder 
creation [reference is made to J. Eder, et. al., "Self- 
maintained Folder Hierarchies as Document Repositories". 
Int'l Conference on Digital Libraries: Research and Prac- 
tice, Kyoto, Japan, November 2000]. In this dynamic 
foldering system, metadata is in the form of the attribute 
name-value pair. Examples of definition of explicit folder 
creation are: 

[0009] create folder research under / with org=lab 

[0010] create folder 2000 under /*/new with year=2000. 

[001 1] Examples of definition of template-based folder creation 
are: 

[0012] create folder under /research by dept named D-$val 
[0013] create folder under /research by dept/year. 
[0014] Examples of rule-based folder creation are: 
[0015] ru | e ri: create folder old under /* with year < 1998 

[0016] rule r2: create permanent folder public under /re- 

search/*/year:* with clearance < secret and year > 1999. 

[0017] This dynamic foldering system allows distinct values of an 
attribute to be the classification criteria for assigning a 



document to a folder as in template-based folder cre- 
ation. Consequently, the folder hierarchy of this dynamic 
foldering system is driven by the content of the docu- 
ments. 

[0018] yet another conventional dynamic foldering system uti- 
lizes a query language to retrieve some of the information 
from XML documents [reference is made to US 5,418,946]. 
This conventional dynamic foldering system uses the re- 
trieved information to automatically organize a hierarchy 
in which to organize the XML documents. 

[0019] Although these conventional dynamic foldering technolo- 
gies have proven to be useful, it would be desirable to 
present additional improvements. The conventional folder 
definitions mostly address only the domain of the flat data 
model. Many of the conventional dynamic foldering tech- 
nologies assume the metadata appears in the form of a 
name-value attribute pair. Conventional dynamic folder- 
ing technologies do not provide a complete solution to 
cover the hierarchical data model, such as XML, where the 
criteria of a folder may depend on the context of the cri- 
teria of the ancestor folders. Further, the foldering criteria 
associated with a conventional dynamic folder are static, 
requiring determination when the folder is created. There 



is no mechanism in conventional foldering technologies to 
tailor the foldering criteria at the time a user accesses the 
dynamic folder. For example, users may want to define a 
criterion of the folder to be based on the current month. 
[0020] what is therefore needed is a system, a service, a com- 
puter program product, and an associated method for 
creating dynamic folder hierarchies utilizing a context of a 
criteria of ancestor folders and dynamic foldering criteria. 
Further, a dynamic foldering technique is desired that al- 
lows a user to define foldering criteria at the time a user 
accesses a dynamic folder. The need for such a solution 
has heretofore remained unsatisfied. 

[0021] 

Summary of Invention 

[0022] The present invention satisfies this need, and presents a 
system, a service, a computer program product, and an 
associated method (collectively referred to herein as "the 
systerrTor "the present system") for creating a dynamic 
folder hierarchy. The dynamic folder hierarchy is defined 
by a hierarchy of design-time folder groups. The design- 
time folder group is defined by a parameterized query/ 
predicate on a document comprising structured or semi- 



structured data such as an XML document, an item, or an 
object graph. 

[0023] The present system automatically manages the creations 
and deletions of the run-time dynamic folders. The 
present system further automatically manages selection of 
documents, items, or object graphs found in the run-time 
dynamic folders. An item refers to an object that has both 
metadata (can be of hierarchical structure such as XML) 
and one or more contents (structured, semi- or un- 
structured). An object graph refers to a graph structure of 
objects, where the objects can be XML documents, items, 
or other data. The existence of a folder within the present 
system depends on whether any documents in a collection 
of documents being organized by the present system 
meet the criteria for creation of that folder. If none of the 
documents in the collection of documents meet the crite- 
ria for a folder, the folder is not created. 

[0024] The present system utilizes features of structured and 
semi-structured documents, items, or object graphs 
(collectively referenced as documents) to dynamically cre- 
ate the dynamic folders. The documents comprise a self- 
describing data format. The self-describing data format is 
analyzed by the present system to place the documents in 



a dynamic folder hierarchy. For example, an XML docu- 
ment comprises descriptive tags such as <author>. These 
descriptive tags are used by the present system to dy- 
namically organize documents within a dynamic folder hi- 
erarchy. If designed to organized documents based on 
"author", the present system utilizes the <author> tag to 
create dynamic folders based on names of authors and 
conceptually places the document in the appropriate dy- 
namic folders. 

[0025] The documents are not physically placed in a dynamic 

folder by the present system. Rather, the present system 
retrieves a set of documents matching a query; the 
present system follows a path to retrieve documents much 
as a user follows a path in opening folders in a conven- 
tional foldering system to view documents co-located 
based on some criteria. The criteria for creating a dynamic 
folder hierarchy are predetermined by the user. The user 
can modify these criteria without changing the location of 
any of the documents that the dynamic folder hierarchy is 
organizing. Based on the criteria for the dynamic folder 
hierarchy, the dynamic folder hierarchy changes the loca- 
tion of documents within the dynamic folder hierarchy af- 
ter document update without requiring manual interven- 



tion by a user. 

[0026] The present system comprises a query/ predicate for a de- 
sign-time folder group based on which dynamic folders 
are automatically managed, a variable binding mecha- 
nism, automatic identifications of dynamic folders con- 
taining a particular object, parallel navigation, and cus- 
tomized combination of foldering results. The query/ 
predicate for a design-time folder group can be a param- 
eterized query, making the query/predicate more dynamic 
and useful than conventional dynamic foldering tech- 
niques. 

[0027] The present system uses variable binding to provide pow- 
erful query/predicate definitions on hierarchical data or 
graph-structured data. The variable binding mechanism 
for query/predicate definition is very useful for hierarchi- 
cal data and graph-structured data. 

[0028] Given a document, the present system automatically iden- 
tifies which dynamic folders contain the document. The 
automatic identification of the dynamic folders that con- 
tain a particular document is very useful for analyzing the 
semantics of the object. 

[0029] The present system comprises parallel navigation, allow- 
ing a user to navigate along additional paths in a hierar- 



chy and combine the navigation results using set opera- 
tions. The parallel navigation and the customized combi- 
nation of the results provide a very powerful navigation 
mechanism. 

[0030] The present system may be embodied in a utility program 
such as a dynamic folder hierarchy utility program. The 
present system provides means for the user to identify a 
collection of data as input data for which a dynamic folder 
hierarchy may be created by the present system. The 
present system also provides means for the user to spec- 
ify a design-time folder group definition including a set of 
variable binding expressions from which the dynamic 
folder hierarchy is created. The present system further 
provides means by which a user may select a document to 
view or criteria by which a document is found. A user 
specifies the input data, the design-time folder group 
definitions including a set of variable binding expressions, 
and then invokes the dynamic folder hierarchy utility pro- 
gram to create the dynamic folder hierarchy. The user 
then invokes the dynamic folder hierarchy utility program 
to view a document or set of documents by specifying the 
desired dynamic folder(s). 
Brief Description of Drawings 



[0031] The various features of the present invention and the 

manner of attaining them will be described in greater de- 
tail with reference to the following description, claims, 
and drawings, wherein reference numerals are reused, 
where appropriate, to indicate a correspondence between 
the referenced items, and wherein: 

[0032] FIG. 1 is a schematic illustration of an exemplary operat- 
ing environment in which a dynamic folder hierarchy sys- 
tem of the present invention can be used; 

[0033] FIG. 2 is a block diagram of the high-level architecture of 
the dynamic folder hierarchy system of FIG. 1; 

[0034] FIG. 3 is a diagram of exemplary design-time folder group 
definitions used by the dynamic folder hierarchy system of 
FIGS. 1 and 2; 

[0035] FIG. 4 is a diagram of an exemplary dynamic folder hier- 
archy created by the dynamic folder hierarchy system of 
FIGS. 1 and 2; 

[0036] FIG. 5 is a process flow chart illustrating a method by 

which a user operates the dynamic folder hierarchy sys- 
tem of FIGS. 1 and 2; and 

[0037] FIG. 6 is a process flow chart illustrating a method of op- 
eration of the dynamic folder hierarchy system of FIGS. 1 
and 2. 



Detailed Description 



[0038] The following definitions and explanations provide back- 
ground information pertaining to the technical field of the 
present invention, and are intended to facilitate the un- 
derstanding of the present invention without limiting its 
scope: 

[0039] Document: One definition of document is data stored in a 
structured or semi-structured format including items, ob- 
jects, and object graphs. Another definition of document 
is a computer file that contains data that contains at least 
some data in structured or semi-structured format. 

[0040] XML: extensible Markup Language. A standard, semi- 
structured language used for Web documents. During a 
document authoring stage, XML "tags" are embedded 
within the informational content of the document. 

[0041] internet: A collection of interconnected public and private 
computer networks that are linked together with routers 
by a set of standard protocols to form a global, dis- 
tributed network. 

[0042] | tem: an object that has both metadata (can be of hierar- 
chical structure such as XML) and one or more contents 
(structured, semi- or un-structured). 

[0043] object: a graph structure of objects, where the objects 



can be documents, items, or other data. 

[0044] world W ide Web (WWW, also Web): An Internet client - 

server hypertext distributed information retrieval system. 

[0045] FIG. 1 portrays an exemplary overall environment in which 
a system, a service, a computer program product, and an 
associated method (the "system 10") for creating dynamic 
folder hierarchies for documents according to the present 
invention may be used. System 10 comprises a software 
programming code or a computer program product that is 
typically embedded within, or installed on a host server 
15. Alternatively, system 10 can be saved on a suitable 
storage medium such as a diskette, a CD, a hard drive, or 
like devices. 

[0046] users, such as remote Internet users, are represented by a 
variety of computers such as computers 20, 25, 30, and 
can access the host server 15 through a network 35. In 
one embodiment, system 10 creates dynamic folder hier- 
archies for documents, items, or object graphs stored on 
a data repository 40. Documents, items, or object graphs 
are collectively referenced herein as documents. In an- 
other embodiment, documents organized by system 10 in 
dynamic folder hierarchies are written in XML. Users ac- 
cess the documents through the dynamic folder hierarchy. 



In a further embodiment, users provide documents to sys- 
tem 10; system 10 then creates dynamic folder hierar- 
chies for the user. 
[0047] Computers 20, 25, 30 each comprise software that allows 
the user to interface securely with the host server 15. The 
host server 15 is connected to network 35 via a communi- 
cations link 45 such as a telephone, cable, or satellite link. 
Computers 20, 25, 30, can be connected to network 35 
via communications links 50, 55, 60, respectively. While 
system 10 is described in terms of network 35, computers 
20, 25, 30 may also access system 10 locally rather than 
remotely. Computers 20, 25, 30 may access system 10 ei- 
ther manually, or automatically through the use of an ap- 
plication. 

[0048] FIG. 2 illustrates a high-level architecture of system 10. 
System 10 comprises a query/predicate processor 205, a 
variable binding processor 210 which is a part of 205, an 
automatic identification processor 215, a parallel naviga- 
tion processor 220, and a customizable combination pro- 
cessor 225 which is a part of 220. System 10 automati- 
cally associates a document with dynamic folder hierar- 
chies according to predetermined criteria provided by the 
user. 



[0049] FIG. 3 illustrates a design-tem folder group hierarchy 300 
comprising exemplary design-time folder groups. In 
forming a hierarchy of design-time folder groups, a user 
creates a design-time folder group definition. The de- 
sign-time folder group definition creates a basic hierarchy 
from which dynamic folders are created as needed by sys- 
tem lO.The design-time folder group hierarchy 300 com- 
prises the following design-time folder groups: area 305, 
organization 310, address 315, collaboration 320, per- 
sonname 325, affiliation 330, and companyname 335, 
referenced collectively as design-time folder groups 340. 
The design-time folder groups 340 represent an organi- 
zation of a collection of documents within a predeter- 
mined folder hierarchy. The design-time folder group hi- 
erarchy 300 comprises the design-time folder groups 340 
and the organization of the design-time folder groups 
340 into a hierarchy. 

[0050] | n the example of FIG. 3, system 10 generally assigns 
documents based on information in the document to a 
topic area such as, for example, computers. Area 305 
comprises organization 310 and collaboration 320. Orga- 
nization 310 comprises address 315, representing various 
addresses or locations for each organization represented 



by the collection of documents. Collaboration 320 com- 
prises either individuals (represented by personname 325) 
or companies (represented by companyname 335). Per- 
sonname 325 comprises affiliation 330. 

[0051] The query/predicate processor 205 utilizes parameterized 
queries to define the design-time folder groups 340. For 
the design-time folder groups 340, exemplary parameter- 
ized queries are listed in Table 1. In one embodiment, the 
parameterized queries are queries which evaluate to 
atomic values. The number of dynamic folders in each of 
the design-time folder groups 340 is unknown when the 
design-time folder group hierarchy 300 is designed. 

[0052] Table 1: Exemplary parameterized queries used by the 
query/ predicate processor 205 to associate documents 
with the design-time folder groups 340. 

Table 1 . Exemplary parameterized queries used by the query/predicate 



processor 205 to associate documents with the design-time folder groups 340. 



Design-time Folder Group 


Parameterized Query 


area 305 


//Area/@name 


organization 310 


//Organization/@type 


address 315 


//Address/@city 


collaboration 320 


//Collaboration/@unit 


personname 325 


//Partici pant/I ndividual/@name 


affiliation 330 


//Participant/lndividual/@affiliation 


companyname 335 


//Participant/Company/@name 



[0053] Table 2 illustrates exemplary XML documents that can be 
organized by system 10 into the design-time folder 
groups 340 using the parameterized queries of Table 1. 



The XML documents of table 2 comprise nested tags. The 
entire XML content in the documents are used by the 
query/ predicate processor 205 to determine which docu- 
ments are conceptually placed in a dynamic subfolder. 
Each document may appear in more than one dynamic 
subfolder. 

Table 2 : Exemplary XML documents organized by system 10 into a dynamic 



folder hierarchy. 



Document 


XML structure 


D1 


Organization type- Company" name="XYZ1"> 

<Area name="Computer7> 

<Address city-'San Jose"/> 
</Organization/> 


D2 


Organization type- Company" name="XYZ2"> 

<Area name="Computer"/> 

<Address city="Milpitas"/> 
</Organization/> 


D3 


Organization type- non-Company" name-'XYZ3"> 

<Area name="Computer"/> 

< Address city-'San Jose7> 
</Organization/> 


D4 


<Collaboration unit="Project" name="UVW1"> 
<Area name="Computer"/> 
<Participant> 

<Company name ="XYZ17> 
<lndividual name-'Smith" affiliation="UCLA7> 
</Participant> 
<Collaboration> 


D5 


<Collaboration unit="Project" name="U\AA/2"> 
<Area name="Computer"/> 
<Participant> 

<Company name="XYZ17> 
■individual name-'Smith" affiliation="ABC7> 
<lndividual name-'Jones" affiliation="ABC7> 
</Participant> 
<Collaboration> 



[0054] Given the documents of Table 2, the parameterized 

queries of Table 1, and the design-time folder group hi- 



erarchy 300 of FIG. 3, system 10 creates the dynamic 
folder hierarchy 400 shown in FIG. 4. In one embodiment, 
the dynamic folder hierarchy 400 is created at run-time 
by system 10. Each dynamic folder is specified by a pair: 
an associated design-time folder group definition and a 
distinct value of the query within its parent dynamic 
folder. In one embodiment, the design-time folder group 
definition is a query which evaluates to an atomic value or 
a sequence of atomic values. The pair forms a predicate 
that specifies the dynamic folder. Each dynamic folder is a 
child of the design folder group whose definition gener- 
ates one or more dynamic folders. 

[0055] within area 402, system 10 creates the dynamic folder 
"computer"404. System 10 creates a dynamic folder for 
each "area" represented by the collection of documents 
being organized. Additional "area" folders are created for 
each area represented. In the simple example illustrated 
by the documents of Table 2, only one "area" is repre- 
sented, i.e., computer 404. 

[0056] For each "area" such as computer 404, system 10 creates 
dynamic folders organization 406 and collaboration 408. 
Organization 406 corresponds to organization 315; col- 
laboration 408 corresponds to collaboration 320. Within 



organization 406, system 10 creates a dynamic folder for 
each organization represented by the documents of Table 
2: company 410 and non-company 412. System 10 orga- 
nizes the organization types according to address by cre- 
ating dynamic folders: address 414 for company 410 and 
address 416 for non-company 412. 

[0057] within address 414, system 10 creates a dynamic folder 
for each address found associated with a company in the 
collection of documents to which the design-time folder 
group hierarchy 300 is applied. In the exemplary list of 
documents in Table 2, two addresses are located for doc- 
uments associated with company 410: Milpitas and San 
Jose. Within address 414, system 10 creates Milpitas 418 
and San Jose 420. Milpitas 418 conceptually comprises 
document D2 422. San Jose 420 conceptually comprises 
document Dl 424. One address is located for documents 
associated with non-company 412: San Jose. Within ad- 
dress 416, system 10 creates San Jose 426. San Jose 426 
conceptually comprises document D3 428. 

[0058] System 10 does not move document D2 422, document 
Dl 424, or document D3 428 into a new location. Rather, 
system 10 defines a method by which an external organi- 
zation through parameterized queries can find documents 



that meet criteria in a manner similar to locating docu- 
ments organized within a folder hierarchy. As new distinct 
values are inserted and old distinct values are deleted, ap- 
propriate dynamic folders are conceptually created and 
deleted accordingly. 

[0059] As represented by the documents of Table 2, all of the 

collaboration is by project. Consequently, system 10 cre- 
ates subfolder project 430 of collaboration 408. Collabo- 
ration 408 corresponds to design-time folder group 320. 
Project 430 comprises personname 432. Based on the 
documents of Table 2, system 10 creates two subfolders 
for personname 432: Smith 434 and Jones 436. System 10 
populates affiliation 438, with the affiliations associated 
with Smith 434: UCLA 440 and ABC 442. Document D4 
444 conceptually resides in UCLA 440. Document D5 446 
conceptually resides in ABC 442. The folder, affiliation 
448, associated with Jones 436 comprises ABC 450. ABC 
450 comprises the document D5 446. Personname 432 
corresponds to design-time folder group personnname 
325. Affiliation 438 and affiliation 448 correspond to de- 
sign-time folder group, affiliation 330. 

[0060] System 10 determines one company name among the 

documents in Table 2 that may be organized under col- 



laboration 408. System 10 then creates companyname 
452 and folder XYZ1 454. Folder XYZ1 454 conceptually 
comprises document D4 444 and document D5 446. 
Companyname 452 corresponds to design-time folder 
group, companyname335. 
[0061] within the structure of the dynamic folder hierarchy 400, 
the documents of Table 1 are conceptually inserted into 
one or more dynamic folders. For example, document Dl 
424 is found in 

[0062] /Area/Computer/Org/Company/Address/"San Jose" and 
its ancestor folders, because 7/Area/@name" evaluates to 
"Computer", "//Organization/@type" evaluates to "Com- 
pany" and 7/Address/@city" evaluates to "San Jose". Sim- 
ilarly, document D2 422 is found in / 
Area/Computer/Org/Company/Address/Milpitas. Docu- 
ment D3 428 is found in / 

Area/Computer/Org/non-Company/Address/"San Jose". 
Document D4 444 is found in two dynamic folders: 

[0063] / 

Area/Com- 
puter/Collabora- 

tion/Project/PersonName/Smith/Affiliation/UCLA, 

[0064] and 



[0065] / 

Area/Com- 

puter/Collaboration/Project/CompanyName/XYZl. 
[0066] Document D5 446 is found in three dynamic folders: 

[0067] / 

Area/Com- 
puter/Collabora- 

tion/Project/PersonName/Smith/Affiliation/ABC, / 

Area/Com- 

puter/Collabora- 

tion/Project/PersonName/Jones/Affiliation/ABC, 
[0068] an d 

[0069] / 

Area/Com- 

puter/Collaboration/Project/CompanyName/XYZl. 
[0070] jo retrieve a set of documents in a dynamic folder, the 
query/ predicate processor 205 executes a query on an 
associated collection of documents. The query intersects 
the predicate of the dynamic folder and the predicates of 
the ancestor dynamic folders of the dynamic folder. A 
query to retrieve the documents residing in San Jose 420 
is formulated by the query/predicate processor 205 as: 



[00 71 ] collection("abc")[(//Area/@name = "Computer") 

[° 072 ] and (//Organization/@type = "Company") 

[0073] anc | (//Address/@city = "San Jose")] This query intersects 
three predicates, retrieving documents associated with 
dynamic folder / 

Area/Computer/Org/Company/Address/"San Jose". 

[0074] a query to retrieve the documents residing in collabora- 
tion 408 is formulated as: 

[0075] collection("abc")[(//Area/@name = "Computer") 

[0076] anc | (//Collaboration/@unit = "Project")] 

[0077] This query intersects two predicates. The query retrieves 
the documents in dynamic folder / 

Area/Computer/Collaboration/Project and its sub dynamic 
folders recursively, comprising: 

[0078] /PersonName/Smith, 

./PersonName/Smith/Affiliation/UCLA, /Per- 
sonName/Smith/Affiliation/ABC, ./PersonName/Jones, 
and /PersonName/Jones/Affiliation/ABC, 
./CompanyName/XYZl. 

[0079] The query/predicate processor 205 comprises an algo- 
rithm for retrieving documents within a dynamic folder, 
where: 



[0080] retrieveDocumentO returns a cursor of a set of documents 

from a given dynamic folder, 
[0081] folderNode.getQueryO returns a predicate of the dynamic 

folder, 

[0082] folderNode.getName() returns a label of the dynamic 
folder 

[0083] folderNode.getValue() returns an atomic value associated 
with the dynamic folder, and 

[0084] folderNode.getCollection() returns all the collections asso- 
ciated with the folder hierarchy of the dynamic folder. 

[0085] An exemplary pseudocode of the query/predicate proces- 
sor 205 is as follows: 

[0086] string retrieveQuery(in: folderNode; in: level) 

[0087] beginparentNode = folderNode. getParent() 
[0088] if (parentNode == null) 
[0089] begin 

[0090] // Current location is root folder. Retrieve the associated 
collections. 

[0091] // System 10 assumes there is a minimum of one collec- 
tion. 

[0092] collections = folderNode. getCollection() 



[0093] // Union all the collections, i.e. (collectionCA") 

|collection("B") | ....) 
[0094] predicate = "(" 

[0095] f or each col in collections 

[0096] predicate = predicate + " collectionf + col.getNameO + ") 

[0097] jf co | j S not t he last onepredicate = predicate + "|" 
[0098] predicate = predicate + ")[" 
[0099] end 

[0100] // c e t all the ancestor predicatesancestorPredicate = re- 
trieveQuery(parentNode, level+l);predicate = ancestor- 
Predicate + "(" + folderNode.getQueryO + " = " 
+folderNode.getValue() + ") "; 

[0101] if ( level ==0) 

[0102] predicate.append(T); 

[0103] e | se 

[0104] predicate.append(" and "); 

[0105] return predicate; 

[0106] end 



[0107] ResultSet retrieveDocument(in: folderNode) 
[0108] begin 

[0109] query = new Statement(retrieveQuery(folderNode, 0)); 
[0110] return query.executeO; 
torn] end 

[0112] In one embodiment, system 10 creates materialized query 
tables to pre-compute results for dynamic folders that are 
frequently accessed. Creating materialized query tables 
accelerates query execution by rewriting the query using 
the pre-computed result. In another embodiment, system 
10 caches some of the results from an immediate folder 
during the navigation to use for further navigating the 
content of any descendent folders. In yet another embodi- 
ment, various indexes can be used or different query en- 
gines can be employed. In a further embodiment, system 
10 incorporates constraints into the design-time folder 
group definitions: 

[0113] year: //Conference[./@year > 2000]/@year 

[0114] The variable binding processor 210 utilizes a variable 
binding in the design-time folder group definitions in a 
hierarchy of design-time folder groups. Variable binding 



assigns a variable to a particular query. Variable binding 
provides a mechanism for relating values when defining a 
design-time folder group hierarchy. Relationships be- 
tween values are reflected when folders are dynamically 
created by system 10. 

[° 115 ] Using variable binding, the design-time folder group defi- 
nitions for personname 335 and affiliation 330 become: 

[0116] PersonName: for $v := //Participant/Individual, 
$v/@name 

[O 117 ] Affiliation: $v/@affiliation, 

[0118] where $v is the variable defined by the user. The design- 
time folder group definitions for personname 335 and af- 
filiation 330 are selected for variable binding because a 
relationship exists between personname 335 and affilia- 
tion 330, as represented by the documents of Table 2. 
The design-time folder group definitions for personname 
335 and affiliation 330 comprise $v to refer to the same 
individual. 

[0119] The remaining design-time folder group definitions have 
the same definitions as previously described. Using vari- 
able binding, the semantics for /Person- 
Name/Smith/Affiliation/UCLA, /Person- 
Name/Smith/Affiliation/ABC and /Person- 



Name/Jones/Affiliation/ABC in / 

Area/Computer/Collaboration/Project are different from 
the ones previously described. The dynamic folder / 
PersonName/Smith/Affiliation/UCLA classifies the projects 
Smith participated in while being affiliated with UCLA. The 
dynamic folder /PersonName/Smith/Affiliation/ABC clas- 
sifies the projects Smith participated in while being affili- 
ated with ABC. 

[0120] The following document, D6, demonstrates the usefulness 

of variable binding: 
[0121] Collaboration unit= ,, Project ,, name= ,, UVW3"> 

[0122] <Area name="Computer'7> 

[0123] <Participant> 

[0124] individual name= ,, Smith"affiliation="UCLA7> 
[0125] individual name="Jones"affiliation="ABC7> 
[0126] </Participant> 
[0127] <Collaboration> 

[0128] System 10 uses variable binding to reflect a relationship 
between individuals and their affiliation. Document D6 
represents two individuals with different affiliations par- 
ticipate in a project collaboration: Smith at UCLA and 



Jones at ABC. Without variable binding, document D6 ap- 
pears in UCLA 440, ABC 442, ABC 450, and a UCLA folder 
under affiliation 448 because the terms UCLA, Smith, 
Jones, and ABC all appear in D6: 

[0129] / 

Area/Com- 
puter/Collabora- 

tion/Project/PersonName/Smith/Affiliation/UCLA, / 

Area/Com- 

puter/Collabora- 

tion/Project/PersonName/Smith/Affiliation/ABC, / 

Area/Com- 

puter/Collabora- 

tion/Project/PersonName/Jones/Affiliation/UCLA, 
[0130] and 

[0131] / 

Area/Com- 
puter/Collabora- 

tion/Project/PersonName/Jones/Affiliation/ABC. 
[0132] Through variable binding, the variable binding processor 
210 recognizes the relationship between individual name 
and affiliation and places D6 only in UCLA 440 and ABC 
450, as illustrated by D6 456 in FIG. 4: / 



Area/Com- 
puter/Collabora- 

tion/Project/PersonName/Smith/Affiliation/UCLA, and 

[0133] / 

Area/Com- 
puter/Collabora- 

tion/Project/PersonName/Jones/Affiliation/ABC 
[0134] a further example of a query using the variable binding 

processor 210 is: collection("abc")[(//Area/@name = 

"Computer") 
[0 1 35] and (//Collaboration/@unit = "Project") 

[0136] anc | (f or $ v : = //Participant/Individual 

[° 137 ] return ($v/@name = "Smith" 

[0138] and $v/@affiliation = "ABC"))] . 

[0139] This query intersects four predicates, retrieving the docu- 
ments in the following dynamic folder: 

[0140] / 

Area/Com- 
puter/Collabora- 

tion/Project/PersonName/Smith/Affiliation/ABC. 
[0141] jf there are sub dynamic folders in the dynamic folder/ 
Area/Com- 



puter/Collabora- 

tion/Project/PersonName/Smith/Affiliation/ABCwith addi- 
tional variable bindings, the query generated by system 
10 will be properly nested XQuery For- 
Let-Where-Orderby-Return (FLWOR) expressions. These 
FLWOR expressions reflect the correct scopes of the vari- 
ables. 

[0142] The variable binding processor 210 utilizes an enhanced 
retrieveQueryO method to manage variable binding. The 
retrieveDocument method is as previously described. The 
term "folderNode.getBindingO'Veturns the binding state- 
ment and "null" in the absence of binding. 

[0143] string retrieveQueryO n: folderNode; in: level, out: nesting) 
begin 

[0144] parentNode = folderNode.getParent() 

[0 14 5] if (parentNode == null) 

[0146] begin collections = folderNode. getCollection() 

[0147] predicate = "("for each col in collections 

[0148] predicate = predicate + " collection(" + col.getNameO + ") 
■I 

[° 149 ] if col is not the last one 



[0150] predicate = predicate + "I" 
[0151] predicate = predicate + ")[" 
[0152] end 

[0153] // G e t all the ancestor predicatesancestorPredicate = re- 

trieveQuery(parentNode, level + 1); 
[0154] jf ( folderNode.getBindingO != null ) 

[0 1 55] // Add the "for ... return ..." clause 

[0156] predicate = 

[0157] ancestorPredicate + "(" + folderNode.getBindingO + " re- 
turn ((" +folderNode.getQuery() + " = " + 
[0 1 58] folderNode.getValueO + ") ";nesting + + ; 

[0159] elsepredicate = 

[° 16 °] ancestorPredicate + "(" + folderNode.getQueryO + " = " 

+folderNode.getValue() + ") "; 
[0161] // Fix the matching brackets 

[0162] if ( level ==0) 

[0163] f 0 r (i := o to nesting)predicate.append("))") 

[0164] predicate.append(T) 

[0165] elsepredicate. appendf and ") 



[0166] return predicate; 
[0167] end 

[0168] External variable definitions in query languages allow val- 
ues to be provided by the external environment. Conse- 
quently, the atomic- valued queries of the design-time 
folder group definitions can be parameterized queries. 
The values of the variables are added to the evaluation 
context before the derived query is evaluated and docu- 
ments in the dynamic folders be retrieved. For example: 

[0169] define variable $x as xs:integer external 

[0170] year: //Conference[./@year> $x]/@year 

[0171] The algorithm to derive the query for retrieving the docu- 
ments in a dynamic folder remains the same as previously 
described except that the variable definitions are added to 
the prolog of the query. 

[0172] System 10 views the design-time folder hierarchy defini- 
tion as a tree with the design-time folder group defini- 
tions as nodes. Given a design-time folder group node N, 
N.getNameO returns the name of the folder group defini- 
tion, and N.getQueryO returns the atomic-valued query of 
the folder group definition. The automatic identification 
processor 215 utilizes the following algorithm to deter- 



mine dynamic folders given a design-time folder hierarchy 
definition and a document: 
[0173] "ExecuteQuery"executes a query on an XML document. 

[0174] PreorderProcess(in: xmLdoc, in: Nr, in: parent_path, in- 

out: pathjist) 
[0175] begin 

[0176] jf (Nr is null)return false; 

[° 177 ] atomic.value = ExecuteQuery(xml_doc, Nr.getQueryO); 

[0178] if (atomic.value is null)return false; 

[0 17 9] this.path = parent.path + 7"+ Nr.getNameO + 7"+ 

atomic.value; 
[0180] f| a g = f a | se ; 

[0181] for (each child node Nc of Nr)if (PreorderProcess(xml_doc, 

Nc, this.path, pathjist) is true)flag = true; 
[0182] jf (flag is false)pathjist.append(thispath); 

[0183] return true; 

[0184] end 

[0185] when "PreorderProcess" is executed with a given docu- 
ment, the root group definition of the hierarchy, an empty 
parent path, and an empty path list, the result path list 



returns the dynamic folders in which the given document 
can be found. As in the examples, the document can also 
be found in the ancestor dynamic folders of the dynamic 
folders listed. To avoid redundancy, the ancestor dynamic 
folders are not included in the list. System 10 examines a 
definition with respect to the algorithm. If a dynamic 
folder satisfies a certain definition, system 10 checks the 
children of the dynamic folder to see if the children satisfy 
the definition. If not, system 10 stops following that path 
because none of the descendants will satisfy the defini- 
tion. 

[0186] External variable definitions are bound before the execu- 
tion of "PreorderProcess". In conjunction with variable 
definitions and variable bindings, system 10 utilizes an 
additional parameter "var_pairs". The parameter 
"var_pairs" is a list of name-value pairs for the variables. 
"PreorderProcess"passes the parameter "var_pairs"to its 
recursive calls and to "ExecuteQuery". "ExecuteQuery"uses 
the parameter "var_pairs"to modify the query and appends 
the parameter "var_pairs"to the pair list if variable bind- 
ings are defined for the current node. 

[0187] A n example of the use of the parameter "var_pairs"is ap- 
plied to affiliation 330. System 10 assumes var_paris = 



{(v, "<lndividual name ="Smith ,, affi Nation = ,, ABC7>")}- 
Consequently, the query becomes: 

[0188] define variable $v {<lndividual 

name="Smith"affiliation= ,, ABC7>}$v/@Affiliationln the 
algorithm described above, system 10 executes the 
queries of the design-time folder group definitions indi- 
vidually. A similar algorithm can compose one large query 
such that the execution of that single query can generate 
the result path list. 

[0189] | n one embodiment, system 10 limits the query of each 
design-time folder group definition to return only one 
distinct atomic value. In this case, the hierarchy of the de- 
sign-time folder groups is fixed; i.e., the hierarchy of the 
dynamic folders at run-time is the same as that in the 
definition time. This embodiment is useful for situations 
when users primarily desire a particular dimension for 
categorizing the documents. Examples of design-time 
folder group definitions in this embodiment are: 

[° 19 °] Computer: //Area[@name = "Computer"]/@name 

[0191] Company: //Organization[@type = "Company"]/@type 

[0192] Project: //Collaboration[@unit = "Project"]/@unitSanJose: 
//Address[@city = " 



[° 193 ] San Jose"]/@city 

[0194] smith: //Participant/lndividual[@name = "Smith"]/@name 

[0195] xYZl: //Participant/Company[@name = "XYZl"]/@name 

[0196] UCLA: //Participant/lndividual[@affiliation 
="UCLA"]/@affiliation 

[0197] or 

[0198] Computer: for $v := //Area/@name = "Computer'Yeturn 
(if($v) then "Computer"else ()) 

[0199] Company: for $v := //Organization/@type = "Com- 
pany'Veturn (if($v) then "Company"else ()) 

[0200] Project: for $v := //Collaboration/@unit = "Projecf'return 
(if($v) then "Projecf'else ()) 

[0201] Sanjose: for $v := //Address/@city = "San Jose'Veturn 
(if($v) then "San Jose"else ())etc. 

[0202] The parallel navigation processor 220 allows parallel navi- 
gation to documents along additional paths in a dynamic 
folder hierarchy. Using parallel navigation, a user can nav- 
igate along different paths in the dynamic folder hierarchy 
in different orders to view categorization of documents. 
The parallel navigation processor 220 in conjunction with 
the customizable combination processor 225 allows a 
user to define set operations on the results of additional 



paths. These set operations comprise a combination of 
intersections, unions, and differences. 

[0203] with the dynamic folder hierarchy of FIG. 4 as an example, 
a user navigates to collaboration 408. The user then navi- 
gates along two paths: PersonName 432 to Smith 434 and 
CompanyName 452 to XYZ1 454. Following a path from 
PersonName 432 to Smith 434, the user retrieves docu- 
ments in the documents/Collabora- 
tion/Project/PersonName/Smith folder. Following a path 
from CompanyName 452 to XYZ1 454, the user retrieves 
documents in the /Collabora- 
tion/Project/CompanyName/XYZl folder. 

[0204] | n the example, the user is interested in projects in which 
an individual named Smith and a company named XYZ1 
participated. The user defines the overall result as the in- 
tersection of results from the paths to the individual 
named Smith and the company named XYZ1. When the 
user navigates to Affiliation 438 then ABC 442, the overall 
result is the intersection of documents in / 
Collaboration/Project/PersonName/Smith/Affiliation/ABC 
and XYZ1 454. 

[0205] | n 0 ne embodiment, system 10 obtains the results of all 
the paths and then applies the defined set operations to 



combine the results into the overall result. The results of 
all the paths may be obtained from Automatic Summary 
Tables (ASTs). In another embodiment, system 10 exam- 
ines the definitions of all the paths and combines and 
rewrites the query or queries. Consequently, system 10 
avoids unnecessary computation and efficiently executes 
the query or queries. 

[0206] The examples and the algorithms previously discussed 
have assumed one collection of documents associated 
with a dynamic folder hierarchy. In one embodiment, sys- 
tem 10 may provide a dynamic folder hierarchy for addi- 
tional collections of documents. In this embodiment, sys- 
tem 10 generates additional dynamic folder hierarchies, 
each of which associates with a set of collections. Some 
overlap may occur between the dynamic folder hierar- 
chies. In a further embodiment, system 10 allows the top 
level predicates of a dynamic folder hierarchy on docu- 
ment collections to determine which document collections 
are associated with each top level sub-tree. In this em- 
bodiment, a single dynamic folder hierarchy is sufficient. 

[0207] | n the examples presented, the data organized by system 
10 into dynamic folder hierarchies are XML documents. 
The data can be easily generalized to items or object 



graphs because the variable binding and the variable defi- 
nition mechanisms can be readily applied to such data. 

[0208] FIG. 5 illustrates a method 500 followed by a user to view 
or retrieve documents. At step 505, the user defines a de- 
sign-time folder group definition. The design-time folder 
group definition creates a basic hierarchy from which dy- 
namic folders are created as needed by system 10. The 
user defines variable binding expressions for the dynamic 
folder hierarchy at step 505 as part of the design-time 
folder group definitions. At step 515, the user creates 
documents, updates documents, or otherwise selects doc- 
uments for which system 10 creates a dynamic folder hi- 
erarchy. Updating a document also comprises deleting a 
document. At step 520, the user views documents using 
system 10. The user may view documents singly or in par- 
allel. Further, the user may select a specific document and 
view the folders with which the document is associated. 

[0209] At decision step 525, the user may choose to return to 

step 515 to create, update, or select documents. If at de- 
cision step 525 the user does not choose to create, up- 
date, or select documents, the user may choose to view 
additional documents at decision step 530. The user may 
view documents at step 520 without changing the design- 



time folder group definitions to accommodate the 
changed document set; system 10 automatically and dy- 
namically modifies the folder hierarchy to reflect any 
changes in specific documents or the collection of docu- 
ments for which system 10 is providing a dynamic folder 
hierarchy. If the user does not wish to view additional 
documents at decision step 530, the user may exit the dy- 
namic folder hierarchy at step 535. 

[0210] FIG. 6 illustrates a method 600 for creating dynamic fold- 
ers from the design-time folder group definition for a col- 
lection of documents. At step 605, system 10 registers 
the design-time folder group definitions provided by the 
user and the variable binding expressions provided by the 
user in step 505. At step 610, system 10 accepts and in- 
dexes documents created, updated, or selected by the 
user in step 515. System 10 accepts the documents, in- 
dexes them, and stores them in a form in which the con- 
tent can be interpreted by system 10. At decision step 
615, the user chooses to update, create, or select addi- 
tional documents, returning to step 610. Otherwise, pro- 
cessing proceeds to decision step 620. 

[0211] At decision step 620, the user chooses to select a docu- 
ment to view or select other viewing criteria. At step 625, 



system 10 translates the query representing the selection 
of document or viewing criteria of decision step 620. Sys- 
tem 10 returns a result of the query to the user at step 
630. Processing then returns to step 615 for additional 
action by the user. If the user does not select a document 
or viewing criteria at decision step 620, processing re- 
turns to step 615 for additional action by the user. 
[0212] steps 625 and 630 comprise a viewing stage of system 
10. A user may find and view a document or set of docu- 
ments inside a specified folder, find or view the folders in 
which a specified document is located, or perform parallel 
navigation. Parallel navigation allows the user to view 
more than one dynamic folders at a time and to combine 
viewing criteria or queries such as unions, intersections, 
etc. 

[° 213 ] It is to be understood that the specific embodiments of 

the invention that have been described are merely illustra- 
tive of certain applications of the principle of the present 
invention. Numerous modifications may be made to the 
system and method for creating dynamic folder hierar- 
chies described herein without departing from the spirit 
and scope of the present invention. Moreover, while the 
present invention is described for illustration purpose only 



in relation to the WWW, it should be clear that the inven- 
tion is applicable as well to, for example, data stored on 
an intranet, a local area network, locally, or any other lo- 
cation accessible by the present invention. Furthermore, 
while the present invention is described for illustration 
purpose only in relation to XML documents, it should be 
clear that the invention is applicable as well to, for exam- 
ple, any form of structured, semi-structured, or non- 
structured data. 



